\section{Benefits of our method}
 
\subsection{Native compilation}
\label{sec-native-compilation}

The \commonlisp{} standards suggests that the \emph{startup
  environment} and the \emph{evaluation environment} may be
different.%
\footnote{Recall that the startup environment is the global
environment as it was when the compilation was initiated, and that the
evaluation environment is the global environment in which evaluations
initiated by the compiler are accomplished.}
Our method allows most evaluations by the compiler to have no
influence in the startup environment.  It suffices to \emph{clone} the
startup environment in order to obtain the evaluation environment.

With the tradition of the startup environment and evaluation
environment being identical, some evaluations by the compiler would
have side effects in the startup environment.  In particular, the
value cells and function cells are shared.  Therefore, executing code
at compile time that alters the global binding of a function or a
variable will also be seen in the startup environment.

As an example of code that should not be evaluated in the startup
environment, consider definitions of macros that are only required for
the correct compilation of some program, as well as definitions of
functions that are only required for the expansion of such macros.  A
definition for this purpose might be wrapped in an \texttt{eval-when}
form with \texttt{:compile-toplevel} as the only \emph{situation} in
which the definition should be evaluated.  When the evaluation
environment and the startup environment are identical, such a
definition will be evaluated in the startup environment, and persist
after the program has been compiled.

\subsection{Bootstrapping}

For the purpose of this paper, we use the word \emph{bootstrapping} to
mean the process of building the executable of some implementation
(the \emph{target} system) by executing code in the running process of
another implementation (the \emph{host} system).  The host and the
target systems may be the same implementation.  In this context, a
\emph{cross compiler} is a compiler that executes in the host system
while generating code for the target system.

When a \emph{host} \commonlisp{} system is used to bootstrap a
\emph{target} \commonlisp{} system, the target system needs its own
definitions of many standard \commonlisp{} features.  In particular,
in order to compile code for the target system in the host system, the
cross compiler needs access to the target definitions of standard
\commonlisp{} macros, in particular the defining macros such as
\texttt{defun}, \texttt{defmacro}, \texttt{defgeneric},
\texttt{defvar}, etc.

It is, of course, not an option to replace the host versions of such
macros with the corresponding target versions.  Doing so would almost
certainly break the host system in irreparable ways.  To avoid that
the system might be damaged this way,
many \commonlisp{} systems have a feature called \emph{package locks}%
\footnote{The name of this feature is misleading.  While it does make
  sure that the protected package is not modified, it also makes sure
  that functions, macros, etc., with names in the package are not
  redefined.  Such redefinitions do not alter the package itself, of
  course.}
which prevents the redefinition of standard \commonlisp{} functions,
macros, etc.

To deal with the problem of bootstrapping, some systems, in particular
SBCL, replace the standard package names by some other names for
target code, typically derived from the standard names in some
systematic way \cite{Rhodes:2008:SSC:1482373.1482380}.  Using
different package names guarantees that there is no clash between a
host package name and the corresponding target package name.  However,
using non-standard package names also means that the text of the
source code for the target will not correspond to the target code that
ends up in the final system.

As an alternative to renaming packages, first-class global
environments represent an elegant solution to the bootstrapping
problem.  In a system that already supports first-class global
environments, creating a new such environment in which the target
definitions are allowed to replace standard \commonlisp{} definitions
is of course very simple.  But even in a host system that does not a
priori support first-class global environments, it is not very
difficult to create such environments.

Making the cross compiler access such a first-class global environment
is just a matter of structuring its environment-lookup functions so
that they do not directly use standard \commonlisp{} functions such as
\texttt{fboundp} or \texttt{fdefinition}, and instead use the generic
functions of the first-class global environment protocol.

\subsection{Sandboxing}

It is notoriously hard to create a so-called \emph{sandbox
  environment} for \commonlisp{}, i.e., an environment that contains a
``safe'' subset of the full language.  A typical use case would be to
provide a Read-Eval-Print Loop accessible through a web interface for
educational purposes.  Such a sandbox environment is hard to achieve
because functions such as \texttt{eval} and \texttt{compile} would
have to be removed so that the environment could not be destroyed by a
careless user.  However, these functions are typically used by parts
of the system.  For example, \clos{} might need the compiler in order
to generate dispatch code.

The root of the problem is that in \commonlisp{} there is always a way
for the user of a Read-Eval-Print Loop to access every global function
in the system, including the compiler.  While it might be easy to
remove functions that may render the system unusable \emph{directly}
such as functions for opening and deleting files, it is generally not
possible to remove the compiler, since it is used at run-time to
evaluate expressions and in many systems in order to create functions
for generic dispatch.  With access to the compiler, a user can
potentially create and execute code for any purpose.

Using first-class global environments solves this problem in an
elegant way.  It suffices to provide a restricted environment in which
there is no binding from the names \texttt{eval} and \texttt{compile}
to the corresponding functions.  These functions can still be
available in some other environment for use by the system itself.

\subsection{Multiple package versions}
\label{sec-multiple-package-versions}

When running multiple applications in the same \commonlisp{} process,
there can easily be conflicts between different versions of the same
package.  First-class global environments can alleviate this problem
by having different global environments for the different applications
causing the conflict.

Suppose, for instance, that applications \emph{A} and \emph{B} both
require some \commonlisp{} package \emph{P}, but that \emph{P} exists
in different \emph{versions}.  Suppose also that \emph{A} and \emph{B}
require different such versions of \emph{P}.  Since the \commonlisp{}
standard has no provisions for multiple versions of a package, it
becomes difficult to provide both \emph{A} and \emph{B} in the same
\commonlisp{} process.

Using first-class global environments as proposed in this paper, two
different global environments can be created for building \emph{A} and
\emph{B}.  These two environments would differ in that the name
\emph{P} would refer to different versions of the package \emph{P}.

\subsection{Separate environment for each application}

Taking the idea of \refSec{sec-multiple-package-versions} even
further, it is sometimes desirable for a large application to use a
large number of packages that are specific to that application.  In
such a situation, it is advantageous to build the application in a
separate global environment, so that the application-specific packages
exist only in that environment.  The main entry point(s) of the
application can then be made available in other environments without
making its packages available.

Using separate first-class global environments for this purpose would
also eliminate the problem of choosing package names for an
application that are guaranteed not to conflict with names of packages
in other applications that some user might simultaneously want to
install.

%%  LocalWords: startup Sandboxing
